home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Internet Info 1994 March
/
Internet Info CD-ROM (Walnut Creek) (March 1994).iso
/
inet
/
internet-drafts
/
cyn
< prev
next >
Wrap
Internet Message Format
|
1993-06-11
|
16KB
Received: from mail.bellcore.com by IETF.CNRI.Reston.VA.US id aa10958;
11 Jun 93 14:00 EDT
Received: from eve (eve.bellcore.com) by mail.bellcore.com (5.65c/2.1)
id AA12091; Fri, 11 Jun 1993 13:57:15 -0400
Return-Path: <dave@mail.bellcore.com>
Received: by eve (4.1/4.7)
id AA24356; Fri, 11 Jun 93 14:01:49 EDT
Date: Fri, 11 Jun 93 14:01:49 EDT
From: Dave Piscitello <dave@mail.bellcore.com>
X-Station-Sent-From: eve.bellcore.com
Message-Id: <9306111801.AA24356@eve>
To: internet-drafts@IETF.CNRI.Reston.VA.US
Subject: revised i-d
Cc: pjs1@eve.bellcore.com
Please post the following revision to draft-tuba-sysids-01.txt
as -02.txt. Thanks in advance for your help.
--------
IETF Page 1
May 27, 1993 System Identifiers for TUBA Internet Draft
Assignment of System Identifiers for TUBA/CLNP Hosts
David M. Piscitello
Bellcore
dave@sabre.bellcore.com
Status of this Memo
This document is an Internet Draft. Internet Drafts are working
documents of the Internet Engineering Task Force (IETF), its
Areas, and its Working Groups. Note that other groups may also
distribute working documents as Internet Drafts.
Internet Drafts are draft documents valid for a maximum of six
months. Internet Drafts may be updated, replaced, or obsoleted by
other documents at any time. It is not appropriate to use
Internet Drafts as reference material or to cite them other than
as a "working draft" or "work in progress."
Please check the Internet Draft abstract listing contained in the
IETF Shadow Directories (cd internet-drafts) to learn the current
status of this or any other Internet Draft.
Introduction
This Internet-Draft specifies methods for assigning a 6 octet
system identifier portion of the OSI NSAP address formats
described in "Guidelines for OSI NSAP Allocation in the Internet"
(RFC1237, 1991), in a fashion that ensures that the ID is unique
within a routing domain. It also recommends methods for assigning
system identifiers having lengths other than 6 octets. The 6
octet system identifiers recommended in this Internet-Draft are
assigned from 2 globally administered spaces (IEEE 802 or
"Ethernet", and IP numbers, administered by the Internet Assigned
Numbers Authority, IANA).
At this time, the primary purpose for assuring uniqueness of
system identifiers is to aid in autoconfiguration of NSAP
addresses in TUBA/CLNP internets (RFC1347, 1992). The guidelines
in this paper also establish an initial framework within which
globally unique system identifiers, also called endpoint
identifiers, may be assigned.
Abstract
This document describes conventions whereby the system identifier
portion of an RFC1237 style NSAP address may be guaranteed
uniqueness within a routing domain for the purpose of
autoconfiguration in TUBA/CLNP internets. The mechanism is
IETF Page 2
Internet Draft System Identifiers for TUBA May 27, 1993
extensible and can provide a basis for assigning system
identifiers in a globally unique fashion.
Acknowledgments
Many thanks to Radia Perlman of Digital Equipment and Ross Callon
of Wellfleet Communications for their insights and assistance.
Thanks also to the Ethernet connector to my MAC, which
conveniently and quite inobtrusively fell out, enabling me to get
an entire day's worth of work done without email interruptions.
1. Background
The general format of OSI network service access point (NSAP)
addresses is illustrated in Figure 1.
_______________________________________________
|____IDP_____|_______________DSP______________|
|__AFI_|_IDI_|_____HO-DSP______|___ID___|_SEL_|
IDP Initial Domain Part
AFI Authority and Format Identifier
IDI Initial Domain Identifier
DSP Domain Specific Part
HO-DSP High-order DSP
ID System Identifier
SEL NSAP Selector
Figure 1: OSI NSAP Address Structure.
The recommended encoding and allocation of NSAP addresses in the
Internet is specified in RFC 1237. RFC 1237 makes the following
statements regarding the system identifier (ID) field of the
NSAPA:
1. the ID field may be from one to eight octets in length
2. the ID must have a single known length in any particular
routing domain
3. the ID field must be unique within an area for ESs and
level 1 ISs, and unique within the routing domain for level
2 ISs.
4. the ID field is assumed to be flat
RFC1237 further indicates that, within a routing domain that
conforms to the OSI intradomain routing protocol (ISO 10589,
1992) the lower-order octets of the NSAP should be structured as
the ID and SEL fields shown in Figure 1 to take full advantage of
intradomain IS-IS routing. (End systems with addresses which do
IETF Page 3
May 27, 1993 System Identifiers for TUBA Internet Draft
not conform may require additional manual configuration and be
subject to inferior routing performance.)
Both GOSIP Version 2 (under DFI-80h, see Figure 2a) and ANSI DCC
NSAP addressing (Figure 2b) define a common DSP structure in
which the system identifier is assumed to be a fixed length of 6
octets.
_______________
|<--__IDP_-->_|___________________________________
|AFI_|__IDI___|___________<--_DSP_-->____________|
|_47_|__0005__|DFI_|AA_|Rsvd_|_RD_|Area_|ID_|Sel_|
octets |_1__|___2____|_1__|_3_|__2__|_2__|_2___|_6_|_1__|
Figure 2 (a): GOSIP Version 2 NSAP structure.
______________
|<--_IDP_-->_|_____________________________________
|AFI_|__IDI__|____________<--_DSP_-->_____________|
|_39_|__840__|DFI_|_ORG_|Rsvd_|RD_|Area_|_ID_|Sel_|
octets |_1__|___2___|_1__|__3__|_2___|_2_|__2__|_6__|_1__|
IDP Initial Domain Part
AFI Authority and Format Identifier
IDI Initial Domain Identifier
DSP Domain Specific Part
DFI DSP Format Identifier
ORG Organization Name (numeric form)
Rsvd Reserved
RD Routing Domain Identifier
Area Area Identifier
ID System Identifier
SEL NSAP Selector
Figure 2(b): ANSI NSAP address format for DCC=840
2. Autoconfiguration
There are provisions in OSI for the autoconfiguration of area
addresses. OSI end systems may learn their area addresses
automatically by observing area address identified in the IS-
Hello packets transmitted by routers using the ISO 9542 End
System to Intermediate System Routing Protocol, and may then
insert their own system identifier. (In particular, RFC 1237
explains that when the ID portion of the address is assigned
using IEEE style 48-bit identifiers, an end system can
reconfigure its entire NSAP address automatically without the
need for manual intervention.) End systems that have not been
pre-configured with an NSAPA may also request an address from an
intermediate system their area using (ISO 9542/DAM1, 1992).
IETF Page 4
Internet Draft System Identifiers for TUBA May 27, 1993
2.1 Autoconfiguration and 48-bit addresses
There is a general misassumption that the 6-octet system
identifier must be a 48-bit IEEE assigned (ethernet) address.
Generally speaking, autoconfiguration does not rely on the use of
a 48-bit ethernet style address; any system identifier that is
globally administered and is unique will do. The use of 48-bit/6
octet system identifiers is "convenient...because it is the same
length as an 802 address", but more importantly, choice of a
single, uniform ID length allows for "efficient packet
forwarding", since routers won't have to make on the fly
decisions about ID length (see Perlman, 1992, pages 156-157).
Still, it is not a requirement that system identifiers be 6
octets to operate the the IS-IS protocol, and IS-IS allows for
the use of IDs with lengths from 1 to 8 octets.
3. System Identifiers for TUBA/CLNP
Autoconfiguration is a desirable feature for TUBA/CLNP, and is
viewed by some as "essential if a network is to scale to a truly
large size" (Perlman, 1992).
For this purpose, and to accommodate communities who do not wish
to use ethernet style addresses, a generalized format that
satisfies the following criteria is desired:
o+ the format is compatible with installed end systems
complying to RFC 1237
o+ the format accommodates 6 octet, globally unique system
identifiers that do not come from the ethernet address space
o+ the format accommodates globally unique system identifiers
having lengths other than 6 octets
The format and encoding of a globally unique system identifier
that meets these requirements is illustrated in Figure 3:
Octet 1 Octet 2 Octet 3 ... Octet LLL-1 Octet LLLL
+-----------+-----------+-----------+- ...-+-----------+-----------+
| xxxx TTQQ | xxxx xxxx | xxxx xxxx | | xxxx xxxx | xxxx xxxx |
+-----------+-----------+-----------+- ...-+-----------+-----------+
Figure 3. General format of the system identifier
3.1 IEEE 802 Form of System Identifier
The format is compatible with globally assigned IEEE 802
addresses. Octet 1 identifies a 2 bit qualifier (QQ) and an
optional subtype (TT) whose semantics are associated with the
qualifier. If the qualifier QQ equals 00 or 01, there is no
IETF Page 5
May 27, 1993 System Identifiers for TUBA Internet Draft
subtype (I told you it was optional); the system identifier is
interpreted as a 48-bit, globally unique identifier assigned from
the IEEE 802 committee (an ethernet address). The remaining bits
in octet 1, together with octets 2 and 3 are the vendor code or
OUI (organizationally unique identifier), as illustrated in
Figure 4. The ID is encoded in IEEE 802 canonical form.
Octet 1 Octet 2 Octet 3 Octet 4 Octet 5 Octet 6
+-----------+-----------+-----------+-----------+-----------+-----------+
| VVVV VV00 | VVVV VVVV | VVVV VVVV | SSSS SSSS | SSSS SSSS | SSSS SSSS |
+-----------+-----------+-----------+-----------+-----------+-----------+
|------------vendor code -----------|--------station code---------------|
Figure 4. IEEE 802 form of system identifier
4. Embedded IP Address as System Identifier
If qualifer QQ = 10, the subtype (TT) bits in Figure 3 are
relevant. If the subtype (TT) = 00, then the length of the
system identifier is 48-bits/6 octets. The remaining nibble in
octet 1 is set to zero. Octet 2 is reserved and has a pre-
assigned value (see Figure 5). Octets 3 through 6 contain a
valid IP address, assigned by IANA. Each octet of the IP address
is encoded in binary, in internet canonical form, i.e., the
leftmost bit of the network number first.
Octet 1 Octet 2 Octet 3 Octet 4 Octet 5 Octet 6
+-----------+-----------+-----------+-----------+-----------+-----------+
| 0000 0010 | 1010 1010 | aaaa aaaa | bbbb bbbb | cccc cccc | dddd dddd |
+-----------+-----------+-----------+-----------+-----------+-----------+
|-len&Type--|--reserved-|---------IP address----------------------------|
Figure 5. Embedded IP address as system identifier
As an example, the host "eve.bellcore.com = 128.96.90.55" could
retain its IP address as a system identifier in a TUBA/CLNP
network. The encoded ID is illustrated in Figure 6.
Octet 1 Octet 2 Octet 3 Octet 4 Octet 5 Octet 6
+-----------+-----------+-----------+-----------+-----------+-----------+
| 0000 0010 | 1010 1010 | 1000 0000 | 0110 0000 | 0101 1010 | 0011 0111 |
+-----------+-----------+-----------+-----------+-----------+-----------+
|-len&Type--|--reserved-|---------IP address----------------------------|
Figure 6. Example of IP address encoded as ID
IETF Page 6
Internet Draft System Identifiers for TUBA May 27, 1993
H 2 "Other forms of System Identifiers"
To allow for the future definition of additional 6-octet system
identifiers, the remaining qualifier/subtype values are reserved.
It is also possible to identify system identifiers with lengths
other than 6 octets. Communities who wish to use 8 octet
identifiers (for example, embedded E.164 international numbers
for the ISDN ERA) must use a GOSIP/ANSI DSP format that allows
for the specification of 2 additional octets in the ID field,
perhaps at the expense of the "Rsvd" fields; this document
recommends that a separate Domain Format Indicator value be
assigned for such purposes; i.e., a DFI value that is interpreted
as saying, among other things, "the system identifier encoded in
this DSP is 64-bits/8 octets. The resulting ANSI/GOSIP DSP
formats under such circumstances are illustrated in Figure 7:
______________
|<--_IDP_-->_|______________________________
|AFI_|__IDI__|____________<--_DSP_-->_______|
|_39_|__840__|DFI_|_ORG_|RD_|Area_|_ID_|Sel_|
octets |_1__|___2___|_1__|__3__|_2_|__2__|_8__|_1__|
Figure 7a: ANSI NSAP address format for DCC=840, DFI=foo
_______________
|<--__IDP_-->_|___________________________________
|AFI_|__IDI___|___________<--_DSP_-->____________|
|_47_|__0005__|DFI_|AA_|_RD_|Area_|ID_|Sel_|
octets |_1__|___2____|_1__|_3_|_2__|_2___|_8_|_1__|
IDP Initial Domain Part
AFI Authority and Format Identifier
IDI Initial Domain Identifier
DSP Domain Specific Part
DFI DSP Format Identifier
AA Administrative Authority
RD Routing Domain Identifier
Area Area Identifier
ID System Identifier
SEL NSAP Selector
Figure 7b: GOSIP Version 2 NSAP structure, DFI=bar
Similar address engineering can be applied for those communities
who wish to have shorter system identifiers; have another DFI
assigned, and expand the reserved field.
IETF Page 7
May 27, 1993 System Identifiers for TUBA Internet Draft
5. Conclusions
This proposal should debunk the "if it's 48-bits, it's gotta be
an ethernet address" myth. It demonstrates how IP addresses may
be encoded within the 48-bit system identifier field in a
compatible fashion with IEEE 802 addresses, and offers guidelines
for those who wish to use system identifiers other than those
enumerated here.
6. References
RFC1237. Callon, R., Gardner, E., and Colella, R. "Guidelines
for OSI NSAP Allocation in the Internet", June 1991.
RFC1347. Callon, R., "TCP/UDP over Big Addresses (TUBA)", May 1992.
ISO 10589. ISO, Intradomain routing protocol for use in conjunction with
ISO 8473, Protocol for providing the OSI connectionless
network service.
ISO 9542. ISO, End-system and intermediate-system routing protocol
for use in conjunction with ISO 8473, Protocol for
providing the OSI connectionless network service.
ISO 9542/DAM1. ISO, End-system and intermediate-system routing protocol
for use in conjunction with ISO 8473, Protocol for
providing the OSI connectionless network service.
Amendment 1: Dynamic Discovery of OSI NSAP Addresses
End Systems.
Perlman Perlman, Radia., Interconnections: Bridges and Routers,
Addison-Wesley Publishers, Reading, MA. 1992.
7. Author Information
David M. Piscitello
Bell Communications Research
NVC 1C322
331 Newman Springs Road
Red Bank, NJ 07701
dave@mail.bellcore.com